libmetal: add metal_list_for_each_safe() support #251
Conversation
yintao707
force-pushed
the
listsafe
branch
4 times, most recently
from
0f6197b to
09cb9bc
Compare
|
hi @arnopo , |
|
hi @yintao707, |
|
|
hi, @arnopo, @edmooring , @tnmysh , |
Please let's time to people to review the patches even if quite simple. One implicite rule is that 2 experts or maintainers has approved the PR. |
lib/list.h
Outdated
| @@ -98,6 +98,10 @@ static inline struct metal_list *metal_list_first(struct metal_list *list) | |||
| (node) != (list); \ | |||
| (node) = (node)->next) | |||
|
|
|||
| #define metal_list_for_each_safe(list, node, temp) \ | |||
There was a problem hiding this comment.
While other APIs are not documented, I prefer we document this API in doxygen format. This will clearly say what is head, node etc..
Ideally I would prefer if we keep order of arguments matching with kernel API of list_for_each_safe. It makes developer's life easy.
@arnopo do you have any preference?
There was a problem hiding this comment.
I agree with both of Tanmay's points.
There was a problem hiding this comment.
Yes make sense
Please @yintao707, update based on @tnmysh remarks
There was a problem hiding this comment.
Yes make sense Please @yintao707, update based on @tnmysh remarks
hi, @arnopo , @tnmysh, @edmooring ,
I have updated this PR， I am not sure if the comments I added are compliant. Please help me review it again, thanks.
The parameters of this API need to be in the same order as the parameters of the Linux API, I think that metal_list_for_each should be modified firstly, this can ensure that the two APIs are consistent, howerver, which will have a lot of impact. so, let's change this in the other PR.
Add a more secure way to traverse linked lists Signed-off-by: Guiding Li <liguiding1@xiaomi.com>
|
This PR is ready to be merged. It will be merged just after the Release v2023.10 |
No description provided.